CONTENTS

Like other definition functions, WDEFs contain executable code that needs to be locked down in memory whenever it is executed. If your application is using a custom WDEF marked as purgeable, the Memory Manager may purge the WDEF resource in order to allocate additional memory in your application heap. The Window Manager will reload the WDEF resource if necessary before calling it. If your application is the "current" application, i.e. the one that is executing but may not necessarily be frontmost, the Window Manager can reload the WDEF resource. Everything works fine.

The following is a sequence of events that may cause the problem to occur: The Window Manager calls your WDEF when it needs to redraw your windows even if your application is not current. It does this by calling your WDEF directly whenever your windows get erased. If the WDEF has been purged, the Window Manager will try to reload the WDEF. Since your application is not the "current" application, your application's context has not been restored and your resource chain is not the current resource chain. As a consequence, the Window Manager attempts to load a WDEF from the wrong resource chain. Since it can't find the WDEF, it calls SysError(87).

1. Most applications use WDEFs for floating windows. As defined by Apple's Human Interface Guidelines (HIG), applications should hide their floating windows before being suspended. Since the windows are invisible, the Window Manager under most circumstances won't try to reload your WDEF if it does get purged.
2. This problem might not be triggered by the fact that applications in the background don't normally allocate a lot of memory. For example, even if the WDEF is marked as purgeable, the Memory Manager may not actually cause your WDEF to be purged.
3. Most applications don't run with very tight memory partitions, so even though a WDEF resource is marked purgeable, it doesn't need to be purged.

The simple fix to the problem of your WDEFs not being able to be reloaded is to mark your WDEFs as non-purgeable. This prevents the Memory Manager from purging the WDEF, so it is always available even if your application is not frontmost.

• Other 'DEF types (CDEFs, MDEFs, etc.) won't exhibit this problem because they don't get called when the application's process globals are not current as in the case of WDEFs. These resources types can remain purgeable.
• WDEFs in the System file (or in an enabler file and probably in extensions such as Aaron) can safely be purged because they are always in the resource chain - no matter which application's process is set up.
• An application with a purgeable WDEF may have code in it that makes it non-purgeable after bringing it into memory - in which case, this problem won't occur.
• Third-party memory utilities may force purging to occur more often, thus exacerbating this problem.
• If there is data embedded in a WDEF and the WDEF gets purged and reloaded, the data will have reverted to its on-disk values. Many popular development tools embed global variables in code resources. (If your WDEF needs to call SetUpA4, you're using one of these development systems.) A WDEF whose variables suddenly change to unexpected values can of course cause any of the crashes normally associated with unexpected values.
• In general, applications should not detach WDEF resources from their resource map (see Technical Q&A TB575: Window Manager Q&A's). However, it's worth noting that detached WDEF resources which are also purgeable can never be reloaded from disk.

• Technical Q&A TB575: Window Manager Q&A's